After completing this lesson, you’ll be able to:
Besides representing all forms of nothing in its interface, FME also allows nothing to be a condition in various tests, lets users set nothing values, and allows bulk updates from one form of nothing to another.
Formats have various ways to represent nothing. However, if they support the concept of null, then FME will read any null attributes with a <null> value.
For a workspace to check for incoming nulls, the Tester transformer has specific operators to test for null, empty, and missing values:
Because the Tester interface is incorporated into many facets of FME (such as the TestFilter transformer or Conditional attributes/parameters), you can test for nulls wherever you find that interface.
The "Attribute Has a Value" test returns true when an attribute is not null AND is not empty AND is not missing - saving you the inconvenience of using those three tests separately.
Many other transformers also allow testing for nulls. For example, the Matcher transformer has options as to whether null values constitute a match:
This parameter lets the workspace author decide whether null, empty, and missing values should be treated as different values.
If set to No, then two features can match even if one has an attribute that is <null> and the other has an attribute that is <missing>.
If set to Yes, then two features can only match when their attributes are the same type of nothing, i.e., when <null> one feature is matched by <null> on the other.
Another example is the AttributeFilter transformer, which has separate output ports for <Empty>, <Missing>, and <Null>:
It's often important to be able to test for and filter null values as part of a data validation process or when a null value would cause problems in a calculation.
However, filtering out null values when writing data is sometimes important. That's because what happens when an attribute set to null is sent to a writer depends significantly on the data format.
If the format supports <null>, the destination dataset will contain <null> attributes.
If the format doesn’t support <null>, then FME will automatically convert the data to the closest representation that is supported.
For example, MapInfo TAB does not have a concept of <null>; instead, text attributes are not written (so FME will read them back as <missing>), and numeric attributes are written as -9999 (which is a MapInfo equivalent to null).
Remember that FME only converts "null" values when the format does not support the current representation. For example, if a feature has an empty attribute value, and the format allows empty values, then FME will not convert the data to a true
<null>.
Various transformers in FME join data; the FeatureMerger, FeatureJoiner, and DatabaseJoiner are all examples.
When joining data, one consideration must be handling null values, particularly null key values in an attribute join.
When FME compares keys, and one key is null, it must consider what action is correct. Should that feature be rejected, or should that feature be joined to other features with a null key?
Similarly, when FME merges attributes, and there is a clash, most transformers have a parameter to specify which takes precedence. But should that action be the same when the attribute with priority has a null value? Should a null overwrite an actual value?
These are all aspects of data joins to consider. Some transformers - for example, the FeatureMerger - have a specific parameter to handle nulls. In general, you should always inspect the documentation for each transformer if you suspect that your data contains null values that need handling.
